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Abstract 

A method is presented for constructing replicated services that retain their availability and 
integrity despite several servers and clients being corrupted by an intruder, in addition to others 
failing benignly. More precisely, a service is replicated by n servers in such a way that a correct 
client will accept a correct server’s response if, for some prespecified parameter k, at least k 
servers are correct and fewer than Jfc servers are corrupt. The issue of maintaining causality 
among client requests is also addressed. A security breach resulting from an intruder’s ability to 
effect a violation of causality in the sequence of requests processed by the service is illustrated. An 
approach to counter this problem is proposed that requires that fewer than k servers are corrupt 
and, to ensure liveness, that k < n - 2t, where t is the assumed maximum total number of both 
corruptions and benign failures suffered by servers in any system run. An important and novel 
feature of these schemes is that the client need not be able to identify or authenticate even a single 
server. Instead, the client is required only to possess at most two public keys for the service. 
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1 Introduction 


Distributed systems sre ofteu structured in terms of clients aid services. A service exports a set of 
commands, which clients invoke by issuing revests to the service. After executing a command the 
service may return an appropriate response to the client that invoked the command. In the simplest 
case, the service is .mplemented by only one server. If this server is not sufficiently immune to failure 
however, then the service must be replicated. 

In hostile environments, replication introduces other problems. For instance, it is often more 
difficult, or at least requires more resources, to protect many servers from corruption by an intruder 
than ,t is to protect only a single server. A replicated service should thus be designed to remain 
avadable and correct despite several servers being corrupted by an intruder (in addition to others 
fading benignly). One way to do this employs the store machine approach [23] to replicating the 
service, so that each server individually computes the result and sends it to the client. If the client 
authenticate, the response from each server and accepts the response, if any, sent by a majority 
of servers, then ,t obtains the correct response if a majority of servers are correct. Such schemes 
however, require that the client be able to identify and authenticate the servers that comprise the 
service This may be difficult if the set of servers can change over time or if there is no trustworthy 
source from which the client can obtain the identities and authentication information of the servers. 

In this paper we propose a combined solution to these problems using the state machine ap- 
proach. In our method, the service is implemented by n servers in snch a way that for some pre- 
specified parameter A, a correct client accepts a response from the service provided that a. least k 
servers are correct. Moreover, if fewer than k servers are corrupt, any response accepted at a correct 
client is guaranteed to have been computed by a correct server. An important feature of this scheme 
is that the client possesses exactly one public key for the service (as opposed to, e.g„ one for each 
server) and can treat the service as a single object for the purposes of authentication. This enhances 
appbcation modularity and significantly simplifies the service interface for clients. We emphasise 

that the client need not know the identity of even a single server to authenticate the response of the 
service. 

Even in a system with fewer than k corrupt servers, at least k correct servers, and the above 
guarantees, correct clients may accept improper responses from the service if an intruder has caused 
t e correct servers to process improper requests or to process requests in an incorrect order. In this 
paper we also discuss this issue. We focus on an attack in which an intruder effects and exploits a 
vio ation of causality in the sequence of requests processed by the service. (While similar to an attack 
escribed m [20], this attack is more severe because it involves corrupt servers.) We also propose a 
way to avoid this attack that requires that the client possess at most one additional public key for 
the service, that fewer than k servers are corrupt, and, to ensure liveness, that k < n - 2t, where t 

is the assumed maximum total number of both corruptions and benign failures suffered by servers 
in any system run. 
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The above discussion may be evocative of the large body of literature providing solutions to 
various distributed computing problems in models where Byzantine failures can occur but authen- 
tication is possible (see [17, 24]). Nevertheless, our work has a somewhat different emphasis: we 
employ specific cryptographic techniques to achieve the aforementioned results, and in fact a signif- 
icant contribution of our work is the demonstration of the practical value of these techniques. Our 
approach thus stands in contrast to the body of literature just described, which typically assumes 
only a conventional digital signature scheme. 

The remainder of this paper is structured as Mows. In section 2 we give a brief overview of 
the state machine approach to replication; for more detail, the reader should see [23]. In section 3 
we enumerate our assumptions about the system. In section 4 we present a method of implementing 
services that provides the availability and integrity guarantees outlined above. In section 5, we 
discuss the importance of maintaining causality among client requests and a method to counter an 
intruder’s attempts to exploit violations of causality. In section 6 we outline related work, and we 

conclude in section 7. 


2 State Machine Replication 

A state machine consists of a set of state variables and exports a set of (possibly parameterized) 
commands. The state variables encode the state of the state machine, and the commands transform 
that state. A client of the state machine invokes a command by issuing a request to the state 
machine. Each command is implemented by a deterministic program and is executed atomically 
with respect to other commands. Commands should be executed by a state machine in an order 
that is consistent with Lamport’s causality relation [16]. That is, two requests from the same client 
should be processed in the order they were issued, and if one request could have caused another from 
a different client, then a state machine receiving both should process the former first. Execution of 
each request results in some response (i.e., output), which we assume is returned to the client that 
issued the request. Responses of a state machine are completely determined by its initial state and 

the sequence of requests it processes. 

State machine replication is a general method of implementing a fault- tolerant service by 
multaneously employing many state machine servers and coordinating client interactions with them. 
If all servers are initialized to the same state, and if all correct servers process the same sequence 
of requests, then all correct servers will give the same response to any given request. By prop- 
erly combining the responses of the servers, where “properly” depends on the type of failures being 
considered, the response of the fault-tolerant service is obtained. 
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3 The System Model 

Our system consist, of a sat of principals, n of which are servers and the remainder of which are 
cheats Ail principals communicate exclusively via a network of arbitrary topology, A principal is 
cornet in a run of the system if i, ^ways satishes its speciflcation. A principal may an altar 

eZloy ’ m”" Vr (C0 ° ieCt ' l^ed, Pr ° PerthS ° l ,h<! “ d *■««. schemes we 

employ. Our fadure model ,s thus most similar to “Bytantine with message authenticatiou ■ 

an mid “P" 1 " ‘ c' “ 0,i0 " S - • Purposeful corruption by 

ruder, we partition the faded principals into two sets: the honest principals and the corrupt 

principals. Formally, the only property that this partitioning must have is that any principal that 

ever suffers "truly Bytantine” failures-i.e., Mures that cannot be classified as faltop crash 

omission, or timing Mures-must be classified an corrupt. In a given system run, we let corrupt and 

correct (in slanted font) denote the numbers of corrupt and correct servers, respectively. 

Although principals fad as a single unit, it is convenient to view each principal as consisting of 

gically separate modules (See figure 1.) More precisely, each server consists of a common, cat, on 

odufe, coordination module, and an application module. The communication module is closes, to 

the network, the appheation module is furthest, and the coordination module lies in between The 

appheat, on module of a server is simply a state machine as described in section 2. The coordination 

* 7 ‘.T* (C ’ fr0m diw “ c “ d "i* 1 " intent, m, to that state machine by calling 

tt h d T P <C ’ m> 0n ‘ he end ° f 1 US * ° f re, "” ,S '° be «“« h avadable 

the s'eu th , “‘ Ume ‘ hlt CaUS ‘° ™ sequentially, in 

he sense that a call to deliver is no. made until all previous calls to deliver have returned. Using 

e primitives supphed by the communication module, the coordination module also implements a 

pond primitive response, m) by which the state machine can send a response m to a client c 

.• ' »»»* implements two communication primitives for use by the coordina- 

oduie. The first is a send primitive se nd(c, m) by which the coordination moduie can send a 
message to a cheat: this is presumably u red in the implementation of response, m) and will not be 

r T m PaP ”' The SK °° d 13 “ at0m ' c broadcas ‘ primitive abcast(m) by which a server 
s can broadcast a message (s, m) to the other servers. Servers’ coordination modules communicate 

exclusively through the ure of this broadcast primitive. A server's communication module recei„es 

at”thTend of ” r ,°7 ! “ d W '' h COMCn,s m ’ by caUin * receive((s, m)), which places (s,m) 

rt the end of a hs .of received messages that is available to be read by the coordination module. 

of ( < n "f T °, yfr0m SerVMS ’ iCCOrdin? to " 1,omic broadcast protocol S that is tolerant 

< *"T he ” cefor * h we «»« » «ot»l of at most t servers fail in any system run. 

The protocol H satisfies the following specification. 

Receipt Atomicity: A message is either received at all correct servers exactly once or is never 
received at any correct server. 
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Figure 1: Structure of principals 


(a) Server 


Application Module 
| responcf(c, m) 

deliver((c, m)) jr 

Coordination Module 
^ abcast(m) send(c,m) 

rec eive((s,m)) j | 

Communication Module 


Network 


(b) Client 


Application Module 
| request(m) 

accept(m) [ 

Communication Module 

\ 

Network 


Receipt Validity: A correct server receives a message from a correct server iff the latter previously 
broadcast that message. 

Receipt Order. A correct server receives message (a, m) before another message (s', m') iff all correct 
servers do. That is, all correct servers receive the same sequence of messages. 

Receipt Consistency. The sequence of messages received by an honest server is a prefix of the 
sequence of messages received by a correct server. 


There already exist protocols in the literature that satisfy this specification in various models 
and for various definitions of honest. For instance, if the honest principals are defined to include only 
those principals suffering crash failures, the system is synchronous, and the network is sufficiently 
connected, then the protocol described in [4] for Byzantine failures with authentication satisfies this 
specification for any choice of t < n. Moreover, Chandra [2] has developed randomized 2 protocols 
satisfying the above specification for the same definition of honest in an asynchronous system, by 
combining randomized solutions to consensus [3] and deterministic solutions to reliable broadcast [1]. 
The required relationship between n and t for these protocols depends on the underlying consensus 
and reliable broadcast protocols used. Our protocols do not rely upon any bounds on message 


'It is shown in [12] that even in a synchronous system, any atomic broadcast protocol that is tolerant of omission 
failures and that guarantees consistency with respect to faulty principals requires a majority of correct principals. 
Thus if honest is defined to include those servers that suffer omission failures, the results of th» paper require n > 2 1 . 
is well-known that there is no deterministic solution to consensus, and thus atomic broadcast, in an asynchronous 

system that can suffer even a single crash failure [10]. 
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transmission times, and so the only such bounds required for our results, if any, are those required 
y the particular atomic broadcast protocol used. 

annPir “sT 'T' ^ ‘ W ° m ° dUleS ' " »d a communication module. The 

appb a.,on module of a client c is some client program that can issue a request (c,m) to the service 

by calling request(m). The communication module of the cheat implements this primitive e g by 

signing and broadcasting (c, m) to the entire network. By assuming that this request eventually 

reaches some correct server and by having that server’s communication module forward this request 

y executing abcast((c,m>), the above specification of atomic broadcast can be made to hold for 

c en requests. at is, we assume that servers also implement a protocol, called V. satisfying the 
following properties. 3 6 

Delivery Atomicity: A request is either delivered at all correct servers exactly once or is never 
delivered at any correct server. 

Delivery Validity: A correct server delivers a request from a correct client iff the latter previously 
issued that request. ^ 

Delivery Order. A correct server delivers a request (c,m) before another request (c'.m'i iff all 
correct servers do. That is, all correct servers deliver the same s«,„ence of requests. 

Delivery Consistency: The sequence of requests delivered by an honest server is a preUx of the 
sequence of requests delivered by a correct server. 

Assuming that each server is initialised to the same state, these properties imply that all correct 
and honest servers w,ll produce the same response (or no response) to a given request. The comma- 
meat, on module of a chent accepts a response m for the application module by calling accept(m). 

4 Preserving Integrity and Availability 

presflecified ‘ °“ r *"* ^ the foUow “S P'°P*«i«s, tor some 

Integrity. If corrupt < k, then the response accepted at a correct client, if any, is that computed 
by a correct server. r 


service. 


Availability. If correct > k. then a correct client will accept a response from the 

We satisfy these requirements by replacing the response, m) and accept(m) routines of servers 
and cheats, respect.vely, with two new routines, response, m) and accept^), that will ensure these 
P pert.es. Therefore, the new structures of principals will be as pictured in iigure 2. Although we 
ave replaced the respond routine with respond' a, the interface provided to the application module 
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of each server, we assume that respond is still available for execution by the coordination module. 
Similarly, we assume that accept is still available to the communication module of each client. 

Figure 2: New structure of principals 


(a) Server 


Application Module 
| respond'(c, m) 

deiiver((c, m)) l 

Coordination Module 
| abcast(m) send(c,m) 

receive! (s, m)) j | 

Communication Module 


Network 


(b) Client 


Application Module 
| request(m) 

accept' (m) | 

Communication Module 

1 

Network 


The respond' routines at the different servers will employ a (*, n)-threshold signature scheme. 
A (Jfc,n)-threshold signature scheme is, informally, a method of generating a public key and n shares 
of the corresponding private key in such a way that for any message m, each share can be used to 
produce a partial result from m, where any k of these partial results can be combined into a signature 
for m that can be verified with the public key. Moreover, knowledge of k shares is necessary to sign 
m in the sense that without the private key it is computationally infeasible to (i) create a signature 
for m without k partial results for m, (ii) compute a partial result for m without the corresponding 
share, or (iii) compute a share or the private key without k other shares. 

Cryptanalytic attacks against threshold signature schemes differ from those against their con- 
ventional counterparts in that the cryptanalyst may possess some number of shares and be able to 
acquire partial results, in addition to message/signature pairs. For our purposes, we will say that a 
(fc, n)-threshold signature scheme is secure if, informally, there is no feasible algorithm that, given 
some numbers of these items of information, can perform any of tasks (i)-(iii) above for some new 
message m. Note that to be secure, a signature scheme need not be able to tolerate attacks in which 
a cryptanalyst can see the partial results or the signature for any message of its chotce, as would be 
possible in a chosen message attack. Such attacks can easily be prevented [5]. 

Our respond' routine is not dependent upon any particular implementation of a (*, n)-threshold 
signature scheme, although for concreteness we outline the necessary details of an implementation 
proposed in [7]; a detailed understanding of this scheme is not essential. The scheme begins with 
an RSA [22] public key (e, N) and private key d, where N is the product of two safe primes and 
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tiwCannichael function A is used in place of Euler’s totient function to create e from i. That is 
‘ ~ mCKi where A - jV i is the smallest positive integer such that i'<' v > = i mod y f„ r all 

a € Z^f. The n shares {*}i<;<„ are generated from d in such a way that for any set T C f 1 n ) 
of sir. k £*,(* ’ Pur) ad- 1 mod A(JV), where the integers {p,,r}, €T are fixed o'pnon'and 
°’ L 6 °'° g th ' '‘ th partlal res,ll ‘ for a message m to be u m ,. = m K. mod , v it foUows 
that for any TC of sire *, 4„, r = m . n isT (a m ,.)».r mod iV is a proper signature for m 3 

For our routines we assume that (the coordination module of) each server s, is secretly given 
sole possession of * and any principal can reliably obtain the public key (e, AT) of the service. We do 

t“htt n, I di!,rib “ ,i °“ ° f shares or public keys is accomplished, although we note 

that oil public key systems require similar steps. The integers Pi , T for all i and T can be -hardwired” 

into the implementation of the servers. The response, m) and accept'(m) routines are implemented 


Routine respond*(c , m ) at server a,-: 


1. Execute abcast(a m<i ). 

2. Wait until a set of partial results {u^Jier, |T| = *, for m such that d m , T is a valid 
signature for m, has been received. 

3. Execute respoad(c, (m, A m j)), 

Routine accept* {m) at client c: 


1. If m is not of the form (m*, S), then return to the calling routine. 

2. If S is a valid signature for m', then execute a ccept(m'). 4 

Claim 1 If the threshold signature scheme is secure, then this protocol satisfies Integrity. 


Proof If the signature scheme is secure and corrupt < k, then the corrupt servers cannot generate k 

par ial results from which to sign a message. Thus, the only message that could be properly signed 
is that computed by a correct server. □ 


Claim 2 This protocol satisfies Availability. 


Proof. Suppose that correct 
partial results from k correct 
its response. □ 


> k. By Receipt Validity of 71, all correct servers eventually receive 
servers, and so each correct server can compute a proper signature on 


'For «« of security «d effideucy, .. is advisable dig<llol lhe b , 

the message itself [5], 

Here we do not consider attacks on the freshness of responses [25]. 


as opposed to 
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In terms of communication complexity, in a failure-free run the replacement of respond with 
respond ' results in an additional n executions of 1Z, which can be executed concurrently. Therefore, 
the entire protocol that begins when a client issues a request and ends when it accepts a response 
consists of three communication “phases” that must be executed roughly sequentially: the request 
|jy the client (one execution of "^), the dissemination of partial results (n executions of 7Z.), and the 
sending of the responses (n executions of respond). This protocol can be optimized in at least two 
ways, first by noticing that a client needs to receive only one correctly signed response for Availability 
to be satisfied. This implies that only t + 1 servers need to be designated to respond to any given 
request. In addition, the partial results for the signature of the response need to be broadcast only 
to that set of servers. The set of servers designated to respond to a given request can be fixed in 
advance or determined dyn ami cally. A second optimization is for servers to communicate partial 
results by a reliable broadcast protocol, obtained by removing the Receipt Order requirement and 
appropriately weakening the Receipt Consistency requirement of atomic broadcast. Since reliable 
broadcast is weaker, it possibly can be implemented more efficiently. Reliable broadcast can be used 
because the order in which partial results are received by servers is not important in this protocol. 

Potentially the most computationally expensive part of the algorithm is step 2 of the respond' 
routine, in which the server sorts through the partial results it receives until it finds a T of size k 
such that A m j is a valid signature. The server must examine at most only the first l = min{n, k + t} 
partial results received (from l unique servers), and at most (jj subsets of partial results, because in 
l partial results are at least k correct partial results (if correct > k ). While this could be expensive if 
l is large and Jt w 1/2, the expected search time for a valid signature should be small in the common 
case in most systems, i.e., when n and corrupt are small. One optimization is to have a server always 
include its own index in T (i.e., always include its own partial result in the signature computation). 
Also, certain heuristics, such as using partial results from a combination of servers that previously 
worked, can be used to further reduce the expected search time. Additional optimizations are a topic 
of ongoing research. 

5 Preserving Input Causality 

One guarantee provided in the previous section is that if corrupt < k, then the response accepted at a 
correct client will be the response computed by a correct server. Even the output of a correct server, 
though, may not reflect the way things “should be” if an intruder has caused the service to deliver 
improper requests or to deliver requests in an incorrect order. In general, ensuring proper responses 
from a correct server requires access control , because responses computed from state variables that 
can be written (directly or indirectly) by corrupt clients cannot be trusted. Access control is an 
entire research area in itself and will not be discussed further here. 

In this section we address the issue of ensuring that requests are delivered in a correct order 
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by correct servers. Because we assume an atomic broadcast protocol to disseminate client requests, 
we concern ourselves only with the requirement that correct servers deliver requests in an order 
consistent with causality (see section 2). A common method of preserving causality among client 
requests is for each client to refrain from sending any messages between the time it issues a request 
to the service and the time at which the request is delivered at some honest or correct server [23]. 
Consider the case, however, in which a correct client issues a request to the service, and after receiving 
the request, a corrupt server sends a message to a corrupt client. If the corrupt client subsequently 
issues a request, then there is a causal relationship between the two requests. However, it is not clear 
how this relationship can be detected by correct servers. 

To see why this may be important, suppose that the service of interest is a trading service that 
trades stocks and that a client issues a request to purchase shares of stock through this service. After 
discovering the intended purchase, a corrupt server could collude with a corrupt client as described 
above to issue a request for the same stock to the service. If the correct servers deliver this request 
before that of the correct client, this request may adjust the apparent demand for the stock and 
raise the price offered to the correct client. Thus, by allowing the causally subsequent request of 
the corrupt client to be delivered before the request of the correct client, a type of “insider trading” 
may occur. It is worth noting that access controls alone cannot naturally avoid this problem, as the 
intent is that any client can request to purchase stock at any time. 

In the remainder of this section, we present new request and delivery routines, respectively 
denoted request'(m) and deliver' that replace request(m) and deliver((c,m)). Therefore, if 
used with the respond' and accept' routines of section 4, principals would be structured as in figure 
3. These new routines protect correct clients from the type of attack described above, in the sense 
that any request based on information obtained from a correct client’s request (c, m) can be delivered 
at correct servers only after (c, m). As before, we will use deliver in our implementation of deliver', 
and similarly for request and request 


In the implementation of request^™), the correct client c encrypts m under a public encryption 
key of the service before issuing (c,m). Then, c is provided the following guarantee. The reader 
should verify that this guarantee prevents the aforementioned problem, provided that corrupt < k , 5 
(This k can be chosen independently of that in section 4.) 


Causality: If corrupt < k , then if some request is (i) issued after m is decrypted anywhere (other 

than the sending client), and (ii) delivered at a correct server, then that request is delivered at 
all correct servers after (c, m). 


In addition to satisfying Causality, request' and deliver' must also ensure that client requests are 
delivered according to the specification of atomic broadcast— i.e., that Delivery Atomicity, Delivery 
Validity, Delivery Order, and Delivery C onsistency still hold. The implementations of request' and 

s Here we do not consider traffic analysts attacks [25] or attacks that exploit the malleability of the cryptosystem [8], 


10 



Figure 3: New structure of principals 


(a) Server 

Application Module 
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deliver' ((c, m)) [ 

Coordination Module 
| abcast(m) send(c,m) 

receivers, m)) { | 

Communication Module 
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(b) Client 


Application Module 
| requ est'(m) 

accept' (m) [ 

Communication Module 

1 

Network 


deliver' that we propose satisfy all but the “if” direction of Delivery Validity with no further as- 
sumptions; to ensure that a correct client’s request will eventually be delivered at all correct servers, 

we require k < n — 2 i, and thus n > 2 1. 

Our deliver' routine employs a ( k,n) -threshold cryptosystem. A (fc, n)- threshold cryptosystem 
is, informally, a method of generating a public key and n shares of the corresponding private key in 
such a way that for any message m encrypted under the public key, each share can be used to produce 
a partial result from the ciphertext of m, where any k of these partial results can be combined to 
decrypt m. Moreover, knowledge of k shares is necessary to decrypt m, in the sense that without 
the private key it is computationally infeasible to (i) decrypt m without k partial results for m, 
(ii) compute a partial result for m without the corresponding share, or (hi) compute a share or the 
private key without k other shares. 

As with threshold signature schemes, cryptanalytic attacks against threshold cryptosystems may 
involve the use of partial results and some number of shares, in addition to plaintext/ciphertext pairs. 
For our purposes, we will say that a (fc, n)-threshold cryptosystem is secure if, informally, there is 
no feasible algorithm that, given some numbers of these items of information, can perform any of 
tasks (i)-(hi) above for some new ciphertext m. Again we point out that to be secure, a threshold 
cryptosystem need not be able to tolerate attacks in which a cryptanalyst can see the partial results 
or the plaintext for any ciphertext of its choice, as would be possible in a chosen ciphertext attack. 
This is in accordance with the security of all implementations of threshold cryptosystems thus far 
proposed: all proposed implementations are known to be vulnerable to chosen ciphertext attacks, 
because the conventional cryptosystems on which they are built are vulnerable to such attacks. 

Because the acts of signing a message and decrypting a message are operationally identical in 
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1 r r; “ : ryp,0SI ' S,em ’ « taH— »*» of a <*, „).,hreshold cryptosystem 
can bn obtained Erectly from the (*, n)-,hreshold signature scheme described in section 4 Messages 

»°n,d be encrypted under the pubUc hey (e,,V) of the service in the usual manner, and ^2 
parttai result for an encrypted message m s (m'J- mod IV would be 

4-, e„ n S m K ' mod JT Then, m' . . m . n,er(a™.,)- for any T of sire *. Other 

implemen tattons of threshold cryptosystems have been proposed, based upon both the RSA and 
ElGamaJ [9] cryptosystems [6, 14]. 

Suppose that we are using the RSA threshold cryptosystem described above and .ha, we have 
’ conditions assumed in the previous section; i.e., server s, is secretly given sole possession 
of hf, any principal can reliably obtain the public key (e,N) of the service, and all servers know (a 
pnon) p,, r or all i and T. The basic idea of our algorithm is that each client c encrypts the contents 
O, of „s request with the public key of the service, in an attempt force t servers to cooperate 
o ecrypt ,t. Then, each correct or honest server refrains from broadcasting its partial result for 
( e ciphertext of) m until the delivery sequence through (c,m) is lixed (locally). In this way if 
corrupt < k once a corrupt server codec, s k partial results for m, the sequence of requests through 

c,m has been fixed at some, and thus all, correct servers, and no requests can be placed before 
\c, m; in the delivery sequence at correct servers. 

This algorithm preserve. Causality iff each server requires k partial results for m decrypt 
m. ven under the assumption that this cryptosystem is secure, however, this unfortunately is not 
he case w„h this or any proposed implementation of a (i, n)-,hreshold cryptosystem. The problem 

“ *^/ " : T OC ° “ deSCriW ^ 1 *""* — »• ^osen ciphertext attacks, 

agains w neither the RSA nor the ElGamal cryptosystem (nor any threshold cryptosystem based 

upon them) „ resistant. In our setting, a corrupt server can see at any time how any ciphertext m of 

its choosmg is decrypted, by simply requesting that a corrupt client c issue (c,m) as an apparently 

egitimate request to the service. The corrupt server can then collect * partial results for m to see 
the plaintext to which m decrypts. 

Methods of using chosen ciphertext attacks against the RSA and ElGamal cryptosystems are 
well-known. Here we Ulus, rate one method, originally due to Moore (see [S]), by which a corrupt 

server can decrypt the RSA ciphertext m = (m'J* mod If in a correct client’s request (c, m) without 
waiting to receive k partial results for m. 

1. The corrupt server chooses an arbitrary x and computes y a x» mod N; i.e., x = y* mod If .« 

2. Via a corrupt client, the corrupt server issues a request with contents ym mod If to the service. 


The Ob™*, simpMed fotm lhb ^ whkh , ,„ d , „ ^ „ th „ , , f , , moJ „ con|d 

: r r;i::;rjVeh' r :;:r “.z 

- * — — - 
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3. The corrupt server collects * partial results for ym mod ,V and forms (ym)“ mod N 

4. The corrupt server computes x~ x = y~ d mod N, and then 

x-\ym) d = y~ d y d m d = m d = (m') ed = m! mod N. 


(NB: If x does not have an inverse mod N, then the corrupt server can factor N because 
gcd(x, N ) is a prime factor of N .) 


Similar attacks are possible with the threshold cryptosystems described in [6, 14]. 

Therefore, until a practical threshold cryptosystem is designed that can tolerate chosen cipher- 
text attacks, such attacks must be prevented. A simple way to do this is to have a separate public 
key for each client. That is, the public key for client c, would be a pair and each server 

s . wou ld be given a share K u for use when cooperating to decrypt a request from client c,. This 
prevents chosen ciphertext attacks against the keys and ciphertexts of correct clients, because any 
request received from a corrupt client will be decrypted using the shares of the key for that client, 
and not a correct one. In practice, having separate cryptosystem parameters for each client may 
require that each client be individually “registered” with the service outside of the system before 
employing the service. While this could limit the settings in which our protocols can be used, we 
believe that this is not an unreasonable restriction if maintaining causality among client requests is 

of such importance. 

The one remaining problem in our protocol is that corrupt servers can prov.de incorrect partial 
results that may disrupt the decryption process. Therefore, it must be possible for a server to 
determine when it has properly decrypted a request. To facilitate this, clients are required to send 
with each request a message digest of the request. Message digests have the property that the message 
digest of a given message can be computed efficiently, but it is computationally infeasible to produce 
two messages having the same message digest or to produce any message having a prespeciRe 
target message digest. Accordingly, we henceforth assume that the included message digest uniquely 
identifies, but does not disclose, the contents of the encrypted message and that the joint use o 
the message digests and the threshold cryptosystem does not reveal information that a cryptan yst 
could use to circumvent the properties of either one. The validity of this assumption obviously 
depends on the chosen implementation of message digests. We also note that if the message digest 
function is injective, a message digest does, in fact, uniquely identify a message. Several efficient 
implementations of message digest functions have been proposed (e.g., [IS, 21]) but will not be 
discussed here. Let digest(m ) denote the message digest of m. 

Then, the request' and deliver' routines execute as follows. 


r 0ne suc i, implementation employs a deterministic public key cryptosystem: the digest for a message is comp 
by encrypting the message under an a prion, commonly known public key, for which the corresponding private key has 


been destroyed and is not known. 
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Routine r equest'(m) at client cj : 

1. Create the RSA ciphertext m‘ ss m*. mod Nj and message digest D = digest(m) of m. 

2. Execute request((m\ D)). 

Routine deliver'((cj,m )) at server s,: 

1. If m is not of the form (m\ D), then return to the calling routine. 

2. Execute abcast(a m i ti ), where a m > ti = mod Nj. 

3. Wait until the first k + t partial results |T| = t + t, for m' have been received 

(irom k + t unique servers). 

4. Search for a subset V C T of sire * such that digest(A m ,, T .) = D. If such a r exists and 
A m >j. is a valid request, then execute deliver({ C j, A m , j.)). 

Claim 3 This protocol Saties Delivery Atomicity, Delivery Order, and Delivery Consistency. 

Proof- (Delivery Atomicity) By Delivery Atomicity of V, for each client request deliver' is either 
called exactly once at all correct servers or never called at any correct server. Clearly a request of the 
a er ype is never elivered at any correct server, and so now consider a request (c, m),m = tm' D) 
of the former type. If only fewer than * + 1 partial result, for m' are received at correct servers, ihen’ 
he request w,U never be delivered at any correct server. So, suppose that k + t partial results for 
m are received at all correct servers. Because partial results are broadcast atomically, all correct 
servers employ precisely the same se, (vrW, |T| - * + «, of partial results when attempting 
decrypt m . Therefore, one correct server delivers some request iff all correct servers do and aU 
correct servers deliver the same request, assuming that D uniquely identifies a single request. 

(Delivery Order) By Delivery Order of V, ail servers execute the same sequence of deliver' calls 
And, because any cal to deliver' returns before deliver' is called again, it Mows from Delivery 
Atomicity that all servers execute the same sequence of deliver calls. 

(Delivery Consistency) By Delivery Consistency of V, the sequence of deli ver' calls at an honest 
server ,s a prefix of the sequence of deliver' calls a. a correct server. Moreover, because the sequence 
o messages received at an honest server is a prefix of the sequence of messages received a, a correct 
server (by Receipt Consistency of K), if the honest server receives sufficiently many messages, i, will 
e same set {a m , ,,),, 6T , |T| - k + t, of partial results to decrypt each request as the correct 

servers o. Thus, the sequence of requests delivered at an honest server will be a prefix of the requests 
delivered at a correct server. □ H 

C ^T “ “™* <*«■» « «"»* server, then it cos issved iy that 

client. (That is, the “only if* direction of Delivery Validity holds.) 
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Proof. By Delivery Validity of V, if deliver' ((c,m)) is called at a correct server and c is correct, 
then c must have issued this request. Therefore, a request from a correct client can be delivered at 
a correct server only if the client issued that request. O 

Claim 5 If k < n - 2t, then if a correct client issues a request, it will be delivered at all correct 
servers. (That is, if k < n - 2 1, then the “if” direction of Delivery Validity holds.) 

Proof. By Delivery Validity of V, deliver ' is called exactly once for each request (c, m), m = (m',D), 
issued by a correct client c. If k < n - It, then k + t < n - t < correct, and so at least k + t partial 
results for m' are broadcast and, therefore, received at all correct servers. Since the set of k + t 
partial results used at each correct server contains at least k partial results from k correct servers, 
m' can be decrypted and delivered. □ 

From the above claims, we immediately have the following. 

Claim 0 Ifk< n-2t, this protocol satisfies the specification of atomic broadcast (for client requests). 
We now prove that the above protocol satisfies Causality. 

Claim 7 If the threshold cryptosystem is secure, then this protocol satisfies Causality. 

Proof. Suppose that the threshold cryptosystem is secure and corrupt < k. Then, the earliest point 
at which the ciphertext m' in a request (c, m), m = (m', D), from a correct client c can be decrypted 
anywhere is sometime after some correct or honest server broadcasts its partial result for m' . Let 
s be the first correct or honest server to broadcast its partial result for m! . By Delivery Order and 
Delivery Consistency of V, all correct servers eventually execute (possibly an extension of) the same 
sequence of deliver' calls that s executes. Therefore, all correct servers will execute deiiver'((c, m)) 
before deliver' {(c, m» for any (c, m) issued after m' was decrypted. If all correct servers deliver (the 
plaintext corresponding to) m>, then Causality is satisfied. Moreover, because c is correct, the only 
way in which m! could not be delivered at all correct servers is if the correct servers never receive k + t 
partial results for m> . In this case, the deliver'«c,m)) call at each correct server will never return, 
and no more requests will be delivered at any correct server, thus trivially satisfying Causality. □ 

In a failure-free run, the replacement of deliver with deliver' results in an additional n executions 
of TZ, which can be executed concurrently. Thus, when this protocol is used to disseminate client 
requests and the protocol of section 4 is used to sign responses, the total message complexity is 2n + 1 
broadcasts (n of which can be reliable only; see section 4) and t + 1 responses, structured in four 
communication phases. And, a client may need two public keys for the service, depending on the 

particular cryptosystem and signature scheme used. 

As in the protocol of section 4, step 4 of deliver' is potentially expensive, because it may require 
a server to sort through (*+*) subsets of partial results to be able to decrypt a request. In fact, a 
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th* io to. ' t (Trt r r to sort sb ( - ] subse,s by se,,,ii " g 1 ^ 

ba ‘ d ° “ 0 ‘ matCb ' AS b€f0re ' " ' ely « a small (*«), and a small corrupt in .ha 

common case .o reduce .he expected cos. of decrypting requests from correc. or hones, clien.s. A 

bad request from a corrupt client can be detected in a reasonable amount of time if (*«) ,s smlU , 
and then subsequent requests from that client can be ignored. 

Finally we note that while this protocol prevents a potentially serious attack arising from 
vtolattons of causality, does no. necessarily address all such attacks. A further examination of the 
relationship between security and causality is a topic of ongoing research. 

6 Related Work 

This work was largely inspired by [11J, which presents a replicated, shared key authentication service 
The authentication servtce described there allows two principals to establish a secret, shared encryp. 
ton key provtded that for some prespecified value k, at least k servers are correct and fewer than 
servers are corrupt. The method discussed in the present work cannot immediately be applied to 
construct such a servtce, because of the additional secrecy requirements. However, our method can 
be used .0 construct an analogous public key authentication service and has the additional advantage 

that, unlike the service d. ,J in [11], a client need only possess a. most two keys for the service 
and not one for each serv*. ’ 

Using the state machine approach to construct services tolerant of arbitrary failures with au- 
thent, cation was first considered in [15], Since then, other authors have concentrated upon secure 
rep nation o ata. Secure data replication using quorum methods is considered in (13] for the case 
in which both data integrity and secrecy are important. In these schemes, however, an intruder that 
successfully corrupts a client may also be able to compromise the integrity and secrecy of all data 
Moreover, clients are expected to be able to authenticate data repositories. In [19], a space-efficient 
information dispersal algorithm is developed to facilitate the provision of data integrity and avail- 
ably. The scheme decomposes a flle F into n pieces, each of sire |F|/1, such that any 1 pieces 
suffice to reconstruct F. 


7 Conclusion and Future Work 

We have presented a method for securely replicating services using the state machine approach. 

sing our protocols, a service can be replicated as n servers in such a way that for some prespecified 
parameter k, a cheat will accept a response computed by a correct server provided that a. least 
servers are correct and fewer than k servers are corrupt. We have also addressed the issue of 
ensuring causahty among client requests. A security breach resulting from an intruder’s ability to 
vio ate causality was illustrated, and a safe and live approach was presented to counter this problem, 
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provided that corrupt < k < n - 2t. An important and novel feature of our methods is that they free 
the client of the responsibility of learning the identity and public key of each server. This is achieved 
by employing two recent advances in cryptography, namely threshold cryptosystems and threshold 

signature schemes. 

In addition to those topics of ongoing research mentioned in the previous sections, another direc- 
tion of research is ways to employ the techniques described here in a hierarchical fashion to enhance 
the security of applications. As a simple example of this, one could conceivably employ a different 
replicated service to produce each partial result for a message, and then these partial results could 
be combined to either sign or decrypt this message appropriately. However, the consequences and 
benefits of such designs have not yet been fully investigated and will be discussed further elsewhere. 
Another topic that has not been sufficiently studied is how the detection of corrupt clients and servers 
can be achieved and exploited to optimize our protocols. 
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